我找到了我 Sproutimer 開發時的 22 則。這是唯一逃過清除機制的紀錄，裡面看得到我當時的節奏。

先看第一天：

從打開工具到有一個會跑的計時器，58 分鐘。

我的 prompt 其實很多細節

隔天晚上寫得更完整：

幫我完善 TimerManager.gd：

• 支援三種狀態循環：專注 → 短休息 → 專注 → ... → 第4次專注後 → 長休息
• 每個狀態的時間長度可以從外部設定（預設：專注25分鐘、短休息5分鐘、長休息15分鐘）
• 發出以下信號（signal）：
  • timer_started(state_type)
  • timer_tick(seconds_remaining)
  • timer_completed(state_type, pomodoro_count)
  • timer_paused / timer_resumed
• 支援暫停和繼續

有條列、有預設值、連對外介面要長什麼樣都指定了。三分鐘後的下一則也很清楚：

先用 Godot 預設 UI 風格就好，之後會替換成手繪風格。

這句很重要，它讓 AI 知道現在不用管美觀。

然後我發現，有些指令不是我想的

準備這系列的時，我把開工前在 claude.ai 的規劃對話翻了出來，才發現當時的完整流程。

claude.ai 網頁版幫我把 MVP 拆成六個階段，而且「每個階段都有具體的 Claude Code 提示語可以直接複製貼上使用」。我那幾天貼進 Claude Code 的好幾則指令，都在那個對話裡——包括逐項確認五個 Project Settings 的那則、教我匯出 exe。

所以實際上：網頁版負責規劃和寫 prompt，我負責複製貼上，Claude Code 負責改檔案。

現在來看這是一個耗人力的方法，但其實是個不錯的切分方式——讓一個 AI 在沒有程式碼的情況下想清楚要做什麼，再讓另一個 AI 去執行。我後來在第四版番茄鐘用 plan mode 做的事，本質上是同一件事，只是換成在同一個工具裡完成。

但這次發生問題不在單則 prompt 的品質，而是在於，每一則都只管一個檔案。

一個副作用

因為每則 prompt 都只針對一個檔案，AI 也只看得到那個檔案的上下文。它不知道我三天後會把這個功能拿掉，也不會提醒我「你上禮拜才做過類似的東西」。

它的記憶邊界，只存在於我當下那則 prompt 的視野。而我的視野，就只有眼前那個檔案。

帶走這個：把「規劃」和「執行」放在兩個不同的對話

我當年誤打誤撞做對的一件事，是讓網頁版負責想、Claude Code 負責做。後來我在第四版番茄鐘把它變成刻意的流程：

1. 規劃對話：不碰程式碼，只產出三樣東西——里程碑清單、每個里程碑的驗證方式、風險清單。
2. 執行對話：開場只有一句「請閱讀規劃文件，實作第 N 個里程碑」。
3. 收尾：要求它把「做了什麼、怎麼驗的、什麼還沒驗」寫回文件。

為什麼要分開？因為在同一個對話裡，AI 的 context 容量容易過載，繼而影響到之後的開發與判斷。現行的 LLM 已經有很多可以跨 session 讀取傳送資料或是 subagent 等的方法，可以幫助我們保持單一 session 中 context 的內容性質與減緩使用 context 的速度。

明天講 AI 把 Python 語法寫進 GDScript，我叫它檢討，然後它把教訓寫成了一個檔案——那個檔案到現在還在。